\chapter{Related Work}
\label{chap:relatedwork}
In this chapter existing LMSs will be examined to see how they support the Aalborg PBL model to gain inspiration for how it could be implemented in Moodle.
Furthermore, we will look at student reports from the previous year in order to draw on their experiences with multi-projects, since they worked with a similar topic.
%We are not the first to undertake the task of implementing support for the Aalborg PBL model in an LMS. 
%As Moodle is not the only LMS, it is relevant to examine other LMSs to gain an understanding of how they are typically structured. 
%These may provide inspiration for developing a new system.
%The project that the students from last year worked on is on the same topic, and it is equally relevant to examine their results and extract key points.
%There exist several plugins to Moodle that enhance it in respect to the Aalborg PBL model.
%We will compare the most promising of these plugins and conclude if they can be used.

\section{Learning Management Systems}\label{sec:LMS}
In this section we will examine a number of existing LMSs.
The systems that will be examined are SharePointLMS, Litmos, and Mahara.
We will examine how they handle students, courses, and the concept of groups.
The objective is to gain an understanding of how an extension to Moodle could be structured, and which tools might be relevant to include in the system.

\subsection{SharePointLMS}
SharePointLMS \citep{sharepointlms} is an LMS based on the Microsoft SharePoint platform. 
It offers the basic functionality of an LMS such as course management, student assessment tools such as quizzes and course certificates, conference tools, and document sharing.

In terms of PBL, SharePointLMS offers some relevant features, such as creation of groups.
Within a group it is possible to enable features such as a chat, an internal mail, a calendar and an online conference tool for meetings that could be useful when working in a PBL context.
The only drawback is that groups cannot be created as independent entities in the system, but have to be created in the context of a course.
This does not fit well into the Aalborg PBL model, where a clear distinction exists between courses and projects.

\subsection{Litmos}
Litmos \citep{litmos} is a lightweight LMS with focus on being easy to set up and use.
Its main features are creation of courses including multimedia content such as audio, assessment of students, and surveys to gain feedback on courses.

In contrast to SharePointLMS, Litmos supports creation of groups as independent entities and even creation of groups within a group.
A group can be assigned to a course, which could be utilized to model the way courses are structured at AAU.
This could be achieved by creating one group containing all students on a given semester and then assigning this group to the relevant courses.
Within this group a number of \subgroup{}s would be created, representing project groups.
Litmos has a built-in mailing system and is also integrated with Skype, which could be used to communicate within the groups.


\subsection{Mahara}
Mahara \citep{mahara} is technically not an LMS, but a Personal Learning Environment (PLE), meaning that it is more learner-centered, as opposed to LMSs, which are typically more institution-centered.
However, Mahara still has some features that are relevant to the Aalborg PBL model.

Mahara aims to be an online portal where students can share their work and be members of communities within their area of interest.
However, it does not come with a built-in calendar, which makes planning of projects an issue when using only Mahara.
Mahara compensates for this by providing a sign-on bridge to Moodle, allowing users to access their Moodle accounts directly from Mahara without having to sign in again, and vice versa.

The aspect of Mahara relevant to the Aalborg PBL model is its social networking feature, which allows users to maintain a list of friends and create groups.
Within a group it is possible to create a private forum as well as share files.

Overall Mahara provides a good platform for communicating within project groups, but it lacks support for planning and coordinating the projects.

\subsection{Comparison}
None of the examined LMSs provide complete support for the Aalborg PBL model.
However, they do provide a variety of features that, if combined, would provide the functionality one would expect a PBL-oriented LMS to have.

The group structure found in Litmos could be combined with the features found in SharePoint to create a portal where students could organize their group work.
The functionalities typically provided in LMSs appear to be mostly forums, internal communication and planning tools.
None of the examined systems consider the aspect of communicating with a supervisor.

\section{Relevant Student Reports}
\label{sec:prevwork}
During the spring semester of 2011 a group of students at AAU were given the task of solving a problem similar to ours. 
They had to develop an LMS as a multi-project consisting of four groups, with the goal of fulfilling the needs of the students and faculty of AAU.
However, the solution they developed was created from scratch, unlike our solution, which is an extension of an existing system.
Furthermore, the focus of the earlier project was to develop a solution which fulfilled the needs of teachers and students in relation to courses, whereas our project focuses on developing a solution to better facilitate PBL.

Despite the differences between our project and theirs, we concluded that it would be beneficial for us to examine their development methods and try to learn from their experiences, since the multi-project approach, target group analysis and product testing aspects still remain highly relevant for us. 

We examine the following reports: \emph{E-LMS - Authentication, Database, and Educator} \cite{E-LMS-ADE},  \emph{E-Learning Management System: Implementing Customizable Schedules} \cite{E-LMS-ICS} and \emph{E-LMS - Administration, Calendar, Model, Education, Courses} \cite{E-LMS-ACMEC}.

The following is a list of relevant and interesting observations the groups made in their reports:
\begin{itemize}
	\item{Each group was allowed to pick their own development method, which lead to problems later in the development process as some groups used an agile development method, while others used a traditional method. 
	Integration testing became a problem as the groups were not synchronized and were always in different stages of their development process. 
	Agreeing on a shared development method would have been preferable.}
	\item{Each group sent a representative to meet with representatives from other groups at least once every fortnight, where each representative presented their progress since the previous meeting. 
	As these meetings were primarily for status updates, very little coordination took place between the groups.}
	\item{Every month there would be a large meeting where all the students and supervisors were present and the current status of the system was presented.}
\end{itemize}

Even though we cannot use the product that was developed by the students last semester, we can still use their experiences to improve this project and not make the same mistakes as them.
